home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19950726-19950929 / 000330_news@columbia.edu_Sat Sep 9 11:13:25 1995.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA21269
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Sat, 9 Sep 1995 20:42:45 -0400
  3. Received: by apakabar.cc.columbia.edu id AA13781
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Sat, 9 Sep 1995 20:42:44 -0400
  5. Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!swrinde!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
  6. From: jrd@cc.usu.edu (Joe Doupnik)
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: MS-DOS Kermit 3.14 Second Edition
  9. Message-Id: <1995Sep9.171325.60974@cc.usu.edu>
  10. Date: 9 Sep 95 17:13:25 MDT
  11. References: <3tf3n7$2tl@apakabar.cc.columbia.edu> <2989@sun3.IPSWITCH.COM>
  12. Organization: Utah State University
  13. Lines: 48
  14. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  15.  
  16. In article <2989@sun3.IPSWITCH.COM>, ddl@harvard.edu (Dan Lanciani) writes:
  17. > In article <1995Sep9.114915.60947@cc.usu.edu>, jrd@cc.usu.edu (Joe Doupnik) writes:
  18. > 
  19. > [...]
  20. > |     Ugh(tm). Arcnet with ODI has its share of problems when it comes
  21. > | to ARP.
  22. > 
  23. > ODI makes your application completely media-independent... :) As long
  24. > as your medium looks like Ethernet/802.3/802.5... :(
  25.     Right, sure. I understand ODI rather well, but the picky hardware
  26. dependent things, say the other guy's MAC address, requires special 
  27. handling outside the otherwise CS-clean ODI material. ARP is the dirtiest
  28. of the hardware parts.
  29.  
  30. > |An ARCnet MAC address is one byte long, yet ODI provides six byte
  31. > | MAC addresses. Which end of that string will the byte appear? Undocumented.
  32. > 
  33. > I seem to recall that the answer here is that there isn't a simple answer.
  34. > There is certainly an end where the node id appears (check the ODIPKT sources;
  35. > I forget which end it is), but there are other cases where all six bytes are
  36. > significant.  For example, I think you get into trouble unless you set all
  37. > six bytes to ff for a broadcast, at least on some drivers.
  38.     You are beginning to see what the muddle is.
  39.  
  40. > | The medium ident appearing in an ARP packet reflects the kind of wiring,
  41. > | 6 for Ethernet and presumably 7 for ARCnet. I did make some changes in the
  42. > | MAC address extraction procedure in MSK mark II, and maybe something got
  43. > | broken.
  44. > 
  45. > The poster with the ARCNet problem might want to try running over ODIPKT.
  46. > It understands all these details and presents a fake Ethernet driver
  47. > interface to the client (kermit in this case).  I did all the original
  48. > development with [T]RXNET so it should work with that if anything. :)
  49.     Good suggestion Dan. Tnx.
  50.  
  51. > |     I tested earlier MSK's with ARCnet, and honestly I found that
  52. > | arrangment to be flakey at best. It's not MSK but rather whatever IP
  53. > | routing a NW server does in that case.
  54. > 
  55. > Funny, I've found most users of the server's IP routing features to have
  56. > no trouble.  It does (did?) enforce some subnetting restrictions a little
  57. > too enthusiastically, but I guess one can't blame them for following
  58. > the RFCs...
  59.     It's not straight IP routing that's the problem; it's the media
  60. conversion involved (all that grubby hardware-specific stuff on the ARCnet
  61. side).
  62.     Thanks for the comments,
  63.     Joe D.